#

| Chapter 42 Problems with Terminals |

## 42.2 Fixing a Hung Terminal or Job

Here are a lot of techniques for unlocking a locked-up terminal or window session.

### 42.2.1 Output Stopped?

If your terminal has a HOLD SCREEN or SCROLL LOCK button, did you accidentally press it? Try pressing it and see if things start working. If pressing the button once doesn't fix the problem, you should probably press it once more to undo the screen hold. Otherwise, you may lock up your session worse than it was before!

Another way to stop output is by pressing CTRL-s. The way to restart stopped output is with CTRL-q - try pressing that now. (Unlike a SCROLL LOCK button, though, if CTRL-q doesn't help, you don't need to undo it.)

### 42.2.2 Job Stopped?

If you have a shell prompt (7.1) instead of being in the program you thought you were running - and if your UNIX has job control - you may have stopped a job. Try the jobs command; if the job is stopped, restart it . (12.8)

### 42.2.3 Program Waiting for Input?

The program may be waiting for you to answer a question or type text to its standard input.

> CAUTION: If the program you were running does something that's hard to undo-like removing files-don't try this step unless you've thought about it carefully.

> If your system has job control, you can find out by putting the job in the background with CTRL-z and bg. If the job was waiting for input, you'll see the message:

> >     [1]  + Stopped (tty input)  grep pat

> You can bring the job back into the foreground and answer its question, if you know what that question is. Otherwise, now that the job is stopped, you can kill it. See the following directions.

> On systems without job control, you may be able to satisfy the program by pressing `[RETURN]` or some other key that the program is expecting, like y or n. You could also try pressing `[CTRL-d]` or whatever your "end of input" character is set to. That might log you out, though, unless you've set the ignoreeof variable (3.5).

### 42.2.4 Stalled Data Connection?

If your terminal is hooked to a computer, modem, or network, be sure that the wires haven't come loose.

If you're using a modem and the modem has function lights, try pressing keys and see if the SD or Send Data light flashes. If it does, your terminal is sending data to the host computer. If the RD or Receive Data light flashes, the computer is sending data to your terminal-if you don't see anything, there might be something wrong on your terminal.

If you're connected with rlogin or telnet (1.33), the network to the remote computer might be down or be really slow. Try opening another connection to the same remote host-if you get a response like `Connection` `timed` `out`, you have two choices:

1. Wait for your original connection to unfreeze. The connection may come back and let you keep working where you left off. Or the connection may end when rlogin or telnet notices the network problem.

2. Quit the session and try later.

### 42.2.5 Aborting Programs

To abort a program, most users press CTRL-c. Your account may be set up to use a different interrupt character, like DELETE or RUBOUT. If these don't work, try CTRL-/ (CTRL-backslash). Under most circumstances, this will force the program to terminate. Otherwise, do the following:

1. Log in at another terminal or window.

2. Enter the command `ps -x`. On System V, use `ps -u` `yourname`, where `yourname` is your UNIX username. This displays a list of the programs you are running, something like this:

   >     % ps -x
   >     PID     TTY     STAT    TIME    COMMAND
   >     163     i26     I       0:41    -csh (csh)
   >     8532    i26     TW      2:17    vi ts.ms
   >     22202   i26     S       12:50   vi UNIXintro.ms
   >     8963    pb      R       0:00    ps -x
   >     24077   pb      S       0:05    -bin/csh (csh)
   >     %

3. Search through this list to find the command that has backfired. Note the process identification (PID) number for this command.

4. Enter the command `kill` `PID` (38.10), where PID is the identification number from the previous step. If that doesn't work, try `kill -1` `PID` to send a HUP signal. You may need kill -9, but try the other kills first.

5. If the UNIX shell prompt (like `%` or `$`) has appeared at your original terminal, things are probably back to normal. You may still have to take the terminal out of a strange mode (42.4) though.

   If the shell prompt hasn't come back, find the shell associated with your terminal (identified by a tty number) and kill it. The command name for the C shell is csh. For the Bourne shell, it is sh. In most cases, this will destroy any other commands running from your terminal. Be sure to kill the shell on your own terminal, not the terminal you borrowed to enter these commands. The tty you borrowed is the one running ps; look at the example above and check the `TTY` column. In this case, the borrowed terminal is TTYpb.

   Check ps to ensure that your shell has died. If it is still there, take more drastic action with the command `kill -9` `PID`.

6. Run ps -x again to be sure that all processes on the other tty have died. (In some cases, processes will remain.) If there are still processes on the other tty, kill them.

7. At this point, you should be able to log in again from your own terminal.

The ps (38.5) command, which lists all the programs you are running, also gives you useful information about the status of each program and the amount of CPU time it has consumed. Note that ps lists all the programs you are running, including programs you may not know about (e.g., programs that other programs execute automatically).

- JP, ML

42.1 Making Sense Out of the Terminal Mess |  | 42.3 Why Changing TERM Sometimes Doesn't Work